1. Field of the Invention
The present invention relates generally to improving the security of a webruntime system. More specifically, the present invention relates to using sandboxing technology to improve the security of a webruntime system.
2. Description of the Related Art
A widget (also commonly referred to as a web widget) is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. Widgets are client-side applications that may be authored using web standards and packaged for distribution. They may be downloaded and installed on client machines. A widget may run as a stand-alone application (meaning it can run outside of a Web browser). Widgets are downloadable applications commonly written using HTML, JavaScript, and CSS and utilize web technologies and standards.
The runtime environment in which a widget is run is referred to as a widget user agent or the Web Runtime System (WRT). The WRT is responsible for installation/de-installation of widgets, and to provide functionality for invocation and configuration of the widgets. The WRT is also responsible for the execution of widgets. For example, web widgets are typically written in JavaScript, which is an independent language. The WRT contains a software module, known as a JavaScript engine, to interpret the widget's JavaScript code and perform the execution.
FIG. 1 illustrates an example of a simplified high level architecture diagram of a WRT based on the Limo™ platform (i.e., Linux™ based mobile phone platforms). In this example, at the User Interface (UI) layer, the widgets may perform functions such as providing weather information, a clock, or a photo viewer. There is a Web Runtime UI. At the engine layer, there is a widget engine and a widget manager. At the core layer, there is a Webkit. The Webkit is a library used in Web engines. The WRT is the collection of all components, over and above the Web Engine at the core layer, needed to support installed widgets.
A widget package is a package, conforming to specific standards (e.g. See “Widgets: Packaging and Configuration specification”, W3C Proposed Recommendations, 11 Aug. 2011, published by W3C, the World Wide Web Consortium), containing various files (including configuration documents, icons, digital signatures, etc.) that constitute the implementation of a widget. A widget package contains metadata, which will be referred to in this patent application as the manifest file, for the associated widget. A manifest file specifies a multitude of things of which include the access restrictions for a widget. The access restrictions are used by the WRT to control accesses by a widget to device capabilities, network resources, file system, etc.
There are several different standards bodies that are setting slightly different specifications and standardizations for widgets and JavaScript APIs for widgets. These bodies setting specification for widgets include: W3C, WAC, JIL, BONDI, and Opera among others. As a result, there are different types of widgets and widget runtime systems. Although, the details of the specifications (e.g., how to specify access rights and the granularity of permissions) differ, the general security models and access control enforcement principles of these widget systems are very similar.
The access control enforcements in current WRT implementations are handled by the user-space code of the WRT in the same process that runs the widget itself. For example, these controls and enforcements are handled in Web Engine code as shown in FIG. 2 which shows an overall high level architecture of a BONDI widget implementation having access control features at the Web Engine level.
Referring to FIG. 3, the inventors of the present patent application have recognized that a security vulnerability in conventional WRT arises because the access control enforcement in current WRT implementations is handled by the user-space code of WRT, which is in the same process that runs the widget itself. For example, these controls and enforcements are handled in the Web Engine (e.g. Webkit) code. As illustrated in FIG. 3, a benign process with a legitimate access flow will go through security checks. However, a compromised process has a corrupted access flow that can result in bypassing the mentioned security checks.
Security controls in conventional WRTs are inherently vulnerable and can be bypassed via threats such as address space corruption and code injection. For example, a web engine may contain a bug that allows remote attackers or malicious widgets to inject and run arbitrary code or change the legitimate control flow in that web engine. As a result, an attacker/widget can bypass the security checks and access the restricted resources.
As an illustrative example, Safari™, the popular web browser has several vulnerability types that can result in bypassing security checks. Safari™ is based on the same web engine, called WebKit, which is used in many mobile platforms including iPhone™ and Android™platforms. These vulnerabilities include an execute code vulnerability, an overflow vulnerability, and a memory corruption vulnerability. Safari™ is based on the same Webkit web engine used in many mobile platforms. Thus, there are significant security concerns associated with conventional WRT security controls.
Wholesale Application Community (WAC) defines JavaScript APIs for accessing the device capabilities. The WAC specification is derived from and influenced by earlier specification efforts, such as JIL, BONDI, and also W3C. The JIL and BONDI groups are already joined with WAC and all these efforts and operations are currently under the WAC umbrella now.
WAC APIs includes several methods and properties that are grouped into different modules:                The accelerometer module API that allows using the device accelerometer sensor.        The orientation module API that allows using the device orientation sensor.        The camera module API that enables capturing media through the device camera.        The devicestatus module API that provides access to the device status information.        The filesystem module API that allows accessing the device file system.        The messaging module API that allows message sending and retrieval.        The geolocation module API that exposes the device location (as specified in W3C).        The pim module API that exposes the different PIM (Personal Information Management) functionalities.        The contact module API that enables the management of contact information.        The calendar module API that enables the management of calendar information.        The task module API that enables the management of task information.        The deviceinteraction module API that enables the interaction with the end user through different device capabilities.        
Accesses to the methods and properties of these modules are subject to different policy rules. WAC identifies some of these APIs as “restricted”, also called “sensitive” functions, and accesses to these restricted APIs are controlled by WAC security framework and require user consent.
WAC defines three security domains: “trusted” (aka. WAC domain), “un-trusted” and “operator” (aka. WAC operator) domains. Applications are subject to different security rules depending on which domain they run in. WAC also makes use of a digital signature scheme and the domain of an application is determined based on its digital signature chain. The “operator” domain is intended for use by network service providers. An application runs in operator domain if it has a digital signature that originates from a WAC carrier, i.e., the root of the certificate chain of this application is an operator root certificate. An application runs in trusted domain if its certificate chains to a known WAC root certificate. Otherwise, if the application is not signed or the signature chain does not extend to a WAC root certificate, it runs in an un-trusted domain. FIG. 4 summarizes which domain a widget belongs to based on which conditions.
Accessing restricted APIs typically requires user confirmation due to security controls in place. For example, an application wishing to access a geolocation module API may require that the user provide permission for the application to access this API. This permission can be given on a temporary or a permanent basis. For example, WAC defines 5 different types of user confirmation requirements available for the security controls to place on these APIs:                Allowed: the function can be executing without prompting the user for confirmation        One Shot: the user must be prompted every time to confirm that the function may be executed        Session: the user must be prompted once per session (i.e., when widget is first added to active page) to confirm that the function may be executed        Blanket: the user must be prompted for confirmation the first time that the API function is made by the widget, but once confirmed prompting is never again required.        Deny: is used by operators to indicate that the API function is never permitted.        
Table 1 below depicts an example of restricted functions and their corresponding policy rules for each security domain. This table can be modified by operators to customize the experience. Moreover, users can also configure the policy and choose to use a policy that deviates from the default one provided by the operators.
TABLE 1WACDevice CapabilityUntrustedWACoperatorRationale (“textual interpretation”)accelerometerBlanketPermitPermitAbuse case: Privacy threat, as a widgetPromptcan know if a device is moving,and expose that information though otherAPIs.pim.calendarOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriateprompts. If developers want to enhance theuser experience they can sign the widgetsthrough WAC.pim.calendar.readOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriateprompts. If developers want to enhance theuser experience they can sign the widgetsthrough WAC.pim.calendarwriteOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriateprompts. If developers want to enhance theuser experience they can sign the widgetsthrough WAC.cameraOne-ShotBlanketPermitAbuse case: audio and cameraPromptPromptsurveillancecamera.showPermitPermitPermitcamera.show only adds the ability to attachthe viewfinder to a window object, thus isnot sensitive.camera.captureOne-ShotBlanketPermitAbuse case: audio and cameraPromptPromptsurveillancepim.contactOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriateprompts. If developers want to enhance theuser experience they can sign the widgetsthrough WAC.pim.calendar.readOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriateprompts. If developers want to enhance theuser experience they can sign the widgetsthrough WAC.pim.calendarwriteOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriateprompts. If developers want to enhance theuser experience they can sign the widgetsthrough WAC.deviceinteractionPermitPermitPermitNo significant abuse cases: at most anannoyance could be created bya widget that beeps the phone etccontinuously or at inopportune times.devicestatusSessionBlanketPermitPromptPromptXMLHttpReguestSessionBlanketPermitAbuse case: Excessive network usage, orPromptPromptWARP-declared domains actingas a bridge to malware. SessionPrompt is necessary since WAC has nocontrol over the WARP declarations ofuntrusted widgets.externalNetworkAccessSessionBlanketPermitAbuse case: Excessive network usage, orPromptPromptWARP-declared domains actingas a bridge to malware. SessionPrompt is necessary since WAC hasno control over the WARP declarationsof untrusted widgets.filesystemPermitPermitPermitUncontrolled access to the deviceconditionallyconditionallyfilesystem can lead to a variety of abuseWith Denywith Blanketcases. Widgets are always permitted tofallbackPromptaccess their private storage areas in thefallbackfilesystem. “Permit conditionally” meansthat if the widget is accessing its privatestorage, access is permitted. Otherwise thefallback action applies, e.g. access to otherfilesystem.readPermitPermitPermitUncontrolled access to the deviceconditionallyconditionallyfilesystem can lead to a variety of abuseWith Denywith Blanketcases. Widgets are always permitted tofallbackPromptaccess their private storage areas in thefallbackfilesystem. “Permit conditionally” meansthat if the widget is accessing its privatestorage, access is permitted. Otherwise thefallback action applies, e.g. access to otherfilesystem.writePermitPermitPermitUncontrolled access to the deviceconditionallyconditionallyfilesystem can lead to a variety of abuseWith Denywith Blanketcases. Widgets are always permitted tofallbackPromptaccess their private storage areas in thefallbackfilesystem. “Permit conditionally” meansthat if the widget is accessing its privatestorage, access is permitted. Otherwise thefallback action applies, e.g. access to othermessagingOne-ShotBlanketPermitProvides access to all the messagingPromptPromptfunctionalities.messaging.writeOne-ShotBlanketPermitAbuse case: excessive messaging,PromptPromptmalware spreading, premium ratefraudmessaging.sendOne-ShotBlanketPermitAbuse case: excessive messaging,PromptPromptmalware spreading, premium ratefraudmessaging.findOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriatePrompts. If developers want to enhancethe user experience they can sign thewidgets through WAC.messaging.subscribeOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriatePrompts. If developers want to enhancethe user experience they can sign thewidgets through WAC.orientationBlanketPermitPermitAbuse case: Privacy threat, as a widgetPromptcan know if a device is moving,and expose that information though otherAPIs.pim.taskOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriatePrompts. If developers want to enhancethe user experience they can sign thewidgets through WAC.pim.task.readOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriatePrompts. If developers want to enhancethe user experience they can sign thewidgets through WAC.pim.task.writeOne-ShotBlanketPermitApplications in untrusted domain shouldPromptPromptnot be offered with the opportunity toaccess these features without appropriatePrompts. If developers want to enhancethe user experience they can sign thewidgets through WAC.
An application running within this framework is required to specify and describe in its metadata files (e.g., manifest, widget configuration document, etc.) which APIs and remote network resources it needs to access. These are known as dependencies. The [feature] and [iriset] attributes in metadata files can be used for this purpose. A WAC-capable device can display the statically expressed dependencies (e.g., APIs related to <feature element statements in the widget configuration document) of a widget prior to granting permission for the widget resource to be installed.
There are two main mechanisms in Linux to provide access control: DAC and MAC mechanisms.
In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object will be tested against the set of authorization rules (aka policy) to determine if the operation is allowed.
With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional Unix system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Unlike with DAC, users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users.
DAC mechanisms in current systems provide isolation for the assets of different users. Traditionally, computer systems are designed as multiuser systems. For example, a computer in a company or university can store assets (e.g. files, passwords, programs etc.) of different individuals and serve multiple users simultaneously (e.g. a file server). Traditional DAC (i.e., user/group permissions) determine which users can access which assets and thus provide user-level isolation.
In modern high-end mobile devices, which are indeed single user devices, DAC is used to provide isolation and sandboxing for applications. For example, in Android phones, each application is assigned a user id and runs as if it is a ‘virtual user’. That way, the files that belong to different applications can have different DAC permissions and applications cannot access each other's files due to DAC isolation. Moreover, each application can be controlled to access a particular set of resources it is allowed to access. In Android, for example, when a new application is installed, the system shows the user a list of permissions the app requires and asks whether the user grants those permissions. If the permissions are granted, the system configures this app's DAC permissions in a way that allows the app to access only the resources or services specified by the permissions.
Similarly, a MAC mechanism, for example SMACK, can be used to provide app isolation and sandboxing in a mobile device. SMACK and SELinux are label based MAC mechanisms. We can assign specific (and possible unique) labels to applications and the resources in the system. SMACK and SELinux also use access control policies (i.e., list of access rules that specifies applications with which label can access resources of which label).
Similar to the DAC mechanism described above, it is possible to assign a different label to an application in a mobile phone and pass appropriate policy rules to the MAC mechanism to control which resources and services that application can access to. Based on the permissions granted by the user, a mobile phone system can configure the MAC labels and policy rules of a newly installed application.
In Linux, DAC and MAC are enforced on kernel space objects like files, sockets, directories, and devices. But in a complex system like a smart phone, there can be many objects that are defined in user space which cannot be controlled through DAC or MAC. These objects are created and controlled by processes such as system daemons, framework daemons, etc. If an application needs to access a user space object controlled by a daemon, it needs to send a request to this daemon to retrieve the object. To protect such user space objects, there must be a kind of credential to enforce access rights. A trusted entity should check if an application/process has the rights to access a user space object. In some cases, the daemon of a user space object can perform such security checks and enforcement. If an application and daemon use standard Linux IPC to directly communicate with each other, the daemon can check the credential and access rights of the requesting application, and thus there is no need to introduce a 3rd party process to perform security checks. However, in a smart phone, some services may use intermediary entities like D-bus for communication, service requests, etc. In such cases, the peer's credential is not automatically propagated to the other end of the communication channel and thus a 3rd party trusted entity, which we will call a “security server” in this document, is needed for access control purposes. Such a security server can hand out verifiable credentials to requesting processes and later on can verify the credentials on behalf of other processes that want to check the access rights of the requesting process. Such a scheme can use different form of credentials. In this document, for the sake of simplicity, we will consider a credential to be a random cookie (i.e., a random number) generated by the security server. An example operation flow is given in FIG. 5.
At 500, a cookie is requested by the application process. At 502, the security server retrieves the access rights of the application process and generates a random cookie, saving it along with the access rights. At 504, the security server sends a response to the application process. At 506, the application process requests service using the cookie from the service daemon. At 508, the service daemon asks for a privilege with the given cookie. At 510, the security server checks the privilege and at 512 the security server returns the result to the service daemon. At 512, the service daemon responds to the application process.